There are currently a few trends in networking. One relates to the privacy of communication. Accelerated by the recent pervasive monitoring attempts revealed, more and more traffic is sent end-to-end encrypted. One relevant example is the recently finalized HTTP2.0 protocol (second major version of the Hypertext Transfer Protocol) in IETF (Internet Engineering Task Force), which assumes de facto encryption using TLS (Transport Layer Security) over TCP (Transmission Control Protocol). Similarly, the recently proposed next-generation transport protocol for web by Google, QUIC (Quick UDP Internet Connections), also assumes end-to-end encryption.
Another change relates to the multiplexing of traffic. In the case of best-effort handling at the bottleneck, traffic multiplexing between the same endpoints allows for resource sharing that is more aligned with the QoE-needs (QoE stands for Quality of Experience) of the different streams sharing the same connection. This is why HTTP2.0 also uses the multiplexing paradigm. Similarly, QUIC is also based on the multiplexing paradigm. Another example is WebRTC which multiplexes audio, video streams and potential file transfers onto the same UDP connection. WebRTC is a free, open project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs.
A typical network architecture comprises the presence of network entities, of which later described middleboxes are an example, which are interposed between the nodes. Middleboxes are used for a number of reasons, including implementing acceptable use policies, maintaining regulatory compliance, thwarting attacks, censoring or monitoring users, expanding address space, limiting or balancing resources.
In an all-encrypted, multiplexed world some communication to network middleboxes will still be needed. Middleboxes could have different roles. For example, they may act as Policy Decision Points: they may select domain specific QoS (Quality of Service) solution of flows/packets based on traffic identification, flow states and/or packet handling information. Traditionally in case of broadband traffic DPI/SPI (Deep Packet Inspection/Shallow Packet Inspection) boxes perform this role, but DPI/SPI (Deep Packet Inspection/Shallow Packet Inspection) methods are hardly applicable for encrypted and multiplexed traffic. Signaling based solutions have not gained acceptance due to deployment complexity. They may provide information about the network path, e.g. maximum achievable bitrate, minimum delay, etc. to aid path selection, i.e. to help end-point decide which access to use. They may send advisory messages to applications to help adaptation. Examples for such advisory messages are to provide an initial congestion window or advise up/down-stepping the QoE level in case of adaptive media, based on the congestion status of the network. They may provide transport protocol enhancement in several layers. They may optimize FEC (Forward Error Correction) and retransmission. In general, middleboxes may apply specific treatments to the packets when forwarding those packets to the network nodes, noting that packet treatment includes, but is not limited to, any notorious packet treatment as described for instance in RFC 2474, RFC4221, RFC2598, RFC3260.
All the above roles and functions require some kind of meta-information exchange between the end-points and middleboxes, mostly about traffic characteristics information. Such meta-information refers to information that enables the middlebox to apply a specific treatment to the packet, as also later explained in more detail.
The present invention relates to meta-information reveal by the traffic sender using for instance the same connection, i.e., in-band meta-information reveal by sender. This is a feasible and advantageous, and sometimes unique alternative to other signaling methods. For example, in case of traffic multiplexing, the information revealed may change from packet to packet in a connection. For example, if the endpoints request different traffic treatment for the voice traffic, video traffic and data traffic for a WebRTC connection, then it should be possible for the middlebox to identify the packets belonging to the different streams. This requires some kind of additional packet markings to the middlebox, because the set of five different values that comprise a Transmission Control Protocol/Internet Protocol (TCP/IP) connection (5-tuple) is the same for all the packets.
In some cases, even for a single stream per connection the information to reveal may change from packet to packet, which would require frequent signaling updates if not solved by meta-information including for instance some type of packet markings. In the case of SVC (Scalable Video Coding) videos, for example, the QoS treatment desired may differ depending on which QoS layer a given packet carries.
Another advantage of in-band meta-information reveal is that is always on-path, i.e., the information is attached to the traffic. That is, no problems may arise e.g., due to re-routing (due to e.g., hand-avers) or multi-path delivery.
There are existing methods for in-band meta-information reveal, e.g., by marking the DiffServ Codepoints (DSCP, RFC4594) in the IP packet headers (DiffServ or differentiated services is a computer networking architecture that specifies a simple, scalable and coarse-grained mechanism for classifying and managing network traffic and providing QoS on modern IP networks). However, DiffServ markings are un-encrypted and their usage has been limited to a single-domain, because of the fact that these fields may be easily modified across network domains.
There are different methods to send end-to-end encrypted data between two endpoints. With reference to FIG. 7, the commonly accepted methods use three different pieces of information for encoding: the information to encode 710 (showed as “plain text” in the figure); the encryption key(s) 730; an initialization vector 720 (IV). By means of an encoding algorithm 700, the encoded or cyphered information 740 is obtained.
An initialization vector is a nonce used for data encryption. In this context, “nonce” stands for “number used once” or “number once”. The initialization vector, used only once in any session or connection, prevents repetition of sequences in encrypted text. Identifying such repetitions can help an attacker break a cipher. The initialization vectors or related algorithms and random numbers may be exchanged between the parties during security context setup, but there are algorithms for which the nonce must be unique, but predictability of the initialization vector is acceptable, and may therefore be a simple counter e.g., some unique packet sequence numbers may be used as initialization vector.
The decryption of the encrypted end-to-end data is then the opposite process using some keys and the same initialization vector, shown in FIG. 8. Accordingly, the encoded or cyphered text 710, the IV 820 and the key(s) 830 are used for the decoding (or deciphering) algorithm 800 in order to obtain the deciphered information 840 corresponding to the information 740 of FIG. 7.
It further becomes desirable applying encryption to the meta-information, as this enhances security. For instance, such encryption reduces the risk that the treatment of packets is altered by network nodes that, by getting knowledge of the meta-information, may apply them differently and/or to other packets such that the packets forwarding may not anymore be as intended or desired. Within this context, it has been found that merely encrypting the meta-information at the sender may not be free from problems. It thus becomes necessary finding a suitable way for safely handling meta-information, and to avoid prior art problems related to the handling of meta-information. It is thus an object to provide an improved handling of meta-information.